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Attorney Docket No.: 0203 66-0778 10US 
Client Reference No. : 1778 

LINKING ORDER ENTRY PROCESS TO REALTIME NETWORK 
INVENTORIES AND CAPACITIES 

5 CLAIM OF PRIORITY 

[01] This application claims priority from U.S. Provisional Patent 
Application No. 60/222,791, filed August 1, 2000, entitled "Management of Virtual and 
Physical Network Inventories," which is hereby incorporated by reference, as is set forth in 
full in this document, for all purposes. 

V J 0 CROSS-REFERENCES TO RELATED APPLICATIONS 

[02] This application is related to and claims the benefit of co-pending 

applications No. 09/ , , entitled "MANAGEMENT OF VIRTUAL AND PHYSICAL 

NETWORK INVENTORIES" (Atty. Docket No. 020366-07721 0US); No. 09/ , , 

entitled "PROVISIONING SYSTEM AND METHOD FOR AUTO-DISCOVERING 
L 5 CUSTOMER PREMISES EQUIPMENT IN ACTIVATING xDSL" (Atty. Docket No. 

■ : - 020366-0773 1 0US); No. 09/ , , entitled "PERFORMANCE MODELING IN A VDSL 

NETWORK" (Atty. Docket No. 020366-07741 0US); No. 09/ , , entitled "FAULT 

MANAGEMENT IN A VDSL NETWORK" (Atty. Docket No. 020366-077510US); No. 

09/ , , entitled "FAULT MANAGEMENT IN A VDSL NETWORK" (Atty. Docket 

20 No. 020366-077520US); No. 09/ , , entitled "PROACTIVE REPAIR PROCESS IN 

THE xDSL NETWORK (WITH A VDSL FOCUS)" (Atty. Docket No. 020366-07761 0US); 

No. 09/ , , entitled "PROACTIVE SERVICE REQUEST MANAGEMENT AND 

MEASUREMENT" (Atty. Docket No. 020366-07771 0US), all filed August 1, 2001, the 
disclosures of which are incorporated herein by reference. 

25 

BACKGROUND OF THE INVENTION 
[03] The present invention relates to the linking management of virtual and 
physical network inventories to order entry and capacity checking and more specifically to 



linking management of virtual and physical network inventories to order entry and capacity 
checking for a xDSL network. 

[04] As networks providing digital services to consumers are built out to 
accommodate more consumers, the networks become more complicated and harder to 
5 manage. Additionally, as companies increase capital expenditures to build out these 
networks, more emphasis is focused on increasing the sales of services that are provided 
through a network. In a typical operation, a network may provide data services to and from 
an Internet Service Provider (ISP) and a consumer. Thus, a user typically accesses the 
Internet through the network connection. Additionally, video services may be offered 

10 through the network to provide a consumer with additional choices such as cable T.V. from a 
satellite or cable provider. With the increase in services, continual build-out of the network, 
and the exponentially increasing number of consumers added to these services, it becomes 
increasingly difficult to manage the assets of the network. 

[05] Companies include departments such as sales, engineering, and 

15 marketing that need different views of the same network inventory. However, even if the 
departments interact with the inventory of the network, the inventory is not a complete and 
up-to-date version. For example, a sales department takes orders from customers on the 
assumption that the network is physically able to offer service to the customers. However, 
the sales department takes the order without considering network capacity and/or network 

20 quality. 

[06] Additionally, the marketing department is used to forecast an amount 
of capacity to add to the network. The marketing department, however, does not include in- 
progress network additions or pending sales in their marketing forecast and thus, the 
inventory data used for forecasting capacity is incomplete. Therefore, forecasts to add 

25 capacity to the network may be flawed and inaccurate. 

[07] The engineering department designs and builds out the network after 
receiving the marketing forecast. In building out the network, the engineering department 
plans and installs physical network elements, and assigns virtual paths through the network 
elements to enable service to customers. For example, installing physical network elements 

30 includes installing network elements and associated cards/ports in the network elements that 
enable new customers to receive service. After being installed, identifiers for the new 
ports/cards are manually entered into an inventory data base and manually synched between 
the existing network elements in the inventory data base. Additionally, Interoffice Facilities 
and Fibers (IOF) identifiers are manually inventoried. Thus, identifiers for devices such as 
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DSLAMs, routers, fiber components, and other components of the network are manually 
entered. Also, management of the assignments of logical paths in the network is manual and 
are repeatedly inputted for each network element in the logical path. 

[08] Thus, the management of inventory and the access of inventory are 
manual processes. Additionally, although engineering may manually inventory physical and 
logical network designs, the inventory is not accessed by other departments when making 
decisions. For example, the sales department approves orders for service without referencing 
any capacity or planned information. Basically, the sales department approves any order 
without verifying if the network has capacity to provide the service. Also, the sales 
department does not distinguish between different services that may be offered through the 
network. Thus, network capacity may be filled with less profitable services. Additionally, 
the marketing department produces capacity forecasts without the knowledge of in-progress 
network additions. 

[09] Thus, the departments are making decisions that are dependent on 
actions from each group without information of the other group's actions. This leads to 
inefficient management of network inventory. 

BRIEF SUMMARY OF THE INVENTION 

[10] A method for determining spare capacity for a video and data network 
from a network element database is provided in one embodiment of the invention. In one 
embodiment, the method includes receiving a request for spare capacity in the video and data 
network. In one embodiment, the request includes a service area identifier, which may be a 
telephone number of a customer. Using the service area identifier, equipment is then 
identified and checked for spare capacity. The network element database is checked to 
determine if the identified equipment has spare data and video capacity and if the equipment 
has spare data and video capacity, spare video and data capacity is calculated for the 
identified equipment. 

[1 1] In one embodiment, the video and data network comprises a type of 
Digital Subscriber Line (xDSL) network, such as a Very high bit rate DSL (VDSL) network. 

[12] A further understanding of the nature and advantages of the invention 
herein may be realized by reference of the remaining portions in the specification and the 
attached drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[13] Fig. 1 illustrates a system including components that may be included 
in a network element inventory; 

[14] Fig. 2 illustrates the network of Fig. 1 in more detail; 

[15] Fig. 3 illustrates elements of network element inventory; 

[16] Figs. 4a-d illustrate a process for managing network element inventory; 

[17] Fig. 5 illustrates a method for managing a network element inventory; 

[18] Fig. 6 illustrates elements of a capacity calculating engine 

environment; 

[19] Fig. 7 illustrates a method of determining capacity for a network; and 
[20] Fig. 8 illustrates a method for handling customer inquiries for video 
and data service according to one embodiment. 

DETAILED DESCRIPTION OF THE INVENTION 
[21] Fig. 1 illustrates a system 100 including a network 102 and a network 
element inventory 106. As shown, network 102, an element management system 104, and 
network element inventory 106 are included. 

[22] Network 102 may be any network capable of delivering telephony, or 
high speed data to customers. In one embodiment, network 102 is a xDSL network capable 
of delivering telephony, video, and/or data to customers at high speeds. It is noted for 
purposes of understanding the present invention, the term xDSL is used as a broad label for 
identifying a number of different types of digital subscriber line (DSL) signal formats, such 
as rate adaptive DSL (RADSL), Asymmetric DSL (ADSL), high-bit-rate DSL (HDSL), and 
very-high-data-rate DSL (VDSL). Compatibility for two or more of these formats within the 
same distribution system may also be provided. 

[23] As shown, network 102 includes a shared network 108 and a plurality 
of customer networks 110. Customer networks 110 may be any network connecting the 
customer to shared network 108. A customer network in the plurality of customer networks 
110 may be an individual network for one customer or a network for a group of customers. 
Network 102 includes a plurality of network elements that deliver video and data through 
network 102. 

[24] Shared network 108 may be any network that is shared among plurality 
of customer networks 110. Shared network 108 handles the flow of telephony, video, and/or 
data from a service provider and routes signals to plurality of customer networks 1 1 0, which 
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in turn, routes the signals to individual customers. Additionally, shared network 108 includes 
a video pipe 1 12 and data pipe 1 14. Video pipe 108 delivers video to plurality of customer 
networks 1 10 and data pipe 1 14 delivers data to plurality of customer networks 110. Shared 
network 108 also may be configured to provide telephony service to customers, for example 
5 through data pipe 1 14, or telephony service may be provided through a public switch at a 
central office, as discussed below. 

[25] Element Management System (EMS) 104 may be any application 
capable of receiving/discovering data from shared network 108 and plurality of customer 
networks 110. In one embodiment, EMS 104 is the only system that may configure and/or 
10 access data from shared network 108 and plurality of customer networks 110. The data 
received from the network may include, for example, performance data, fault data, and an 
inventory of network elements. Additionally, EMS 104 may include customer data, which 
includes data relating customers to designated physical and logical paths in shared network 
108 and plurality of customer networks 110. In one embodiment, multiple EMS 104s may be 
15 included and discover data from various elements to network 102. 

[26] Network element inventory 1 06 may be any database capable of 
storing data relating to network 102. In one embodiment, the network element inventory 106 
may receive data from shared network 108 and plurality of customer networks 110 directly 
thereby removing the need for EMS 104. Network element inventory 106 includes network 
20 discovered physical inventory, network discovered logical inventory, and planned network 
inventory in one embodiment. 

[27] In Fig. 2, network 102 is shown in more detail according to one 
embodiment. As shown, shared network 108 includes an external service provider section 
(ESP) 200, a video/data operation center (VDOC) 202, an interoffice facility (IOF) 204, 
25 central office (CO) 206, and midloop 208. In one embodiment, ESP 200 includes ISP 210 
and satellite 212. ISP 210 provides access to the Internet and other data services. Satellite 
212 provides access to video and other video services. While the data and video providers 
are shown as ISP and satellite providers, it will be understood by a person skilled in the art 
that other ways of providing video and data services are possible. 
30 [28] VDOC 202 includes video pipe 1 12 and data pipe 1 14 of Fig. 1. In 

one embodiment, video pipe 1 12 can be configured to deliver video signals to and from ESP 
200 and/or IOF 204 through optic fiber, such as OC-12c, and data pipe 1 14 can be configured 
to deliver data to and from the ESP 200 and/or IOF 204 through optic fiber, such as OC-3c. 
However, in accordance with other embodiments of the invention, video pipe 112 and data 
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pipe 1 14 can utilize any other suitable broadband connection deliver the video and data 
signals, such as other forms of fiber optics, wireless technologies, or the like. Thus, the 
present invention is not limited to the illustrated embodiment. 

[29] In one embodiment, video pipe 112 delivers video using a video 
5 asynchronous transfer mode (ATM) based protocol. In one embodiment, data pipe 1 14 
delivers data using an Internet Protocol (IP) based protocol. 

[30] Video pipe 112 includes a satellite dish 214, video router 216, encoder 
switch 218, and ATM network element (NE) 220. Data pipe 1 14 includes a firewall 222, IP 
switch network element 224, and switch router network element 226. It should be understood 
1 0 that a person of skill in the art will appreciate other ways of implementing video and data 
pipes, such as video head-ends currently known in the art. 

[31] IOF 204 includes synchronous optical network rings (SONET) 248. 
SONET 248 may be any optical network capable of delivering video and data to and from the 
VDOC 202 and central office 206. 
1 5 [32] Central Office (CO) 206 includes an ATM router NE 228 and CO 

Digital Subscriber Loop Access Module (DSLAM) 230. In one embodiment, CO DSLAM 
230 may be a broadband digital terminal (BDT). ATM router NE 224 and CO DSLAM BDT 
230 are coupled to IOF 230 and midloop 208 through optic fiber, such as OC-3c and OC-12c. 
Additionally, CO 206 includes a public switch 230 and Main Distribution Frame (MDF) 234. 
20 Public switch 230 and MDF 234 is where an outside customer network is coupled to the 
shared network. In one embodiment, public switch 232 and MDF 234 provide telephony 
service to a customer. Additionally, MDF 234 is coupled to midloop section 208. 

[33] Midloop 208 includes a RT DSLAM 236 and may include a crossbox 
238. Crossbox 238 provides a connection from shared network 108 to plurality of customer 
25 networks 110. RT DSLAM 236 may include Universal Service Access Multiplexers 
(USAM), Multiple Dwelling Units (MDUs) and/or Broadband Network Units (BNUs). 
Additionally, CO DSLAM 230 is associated to RT DSLAM 236. RT DSLAM 236 may 
include an Optical Network Unit (ONU), which acts as a router for RT DSLAM 236. 

[34] RT DSLAM 236 is a network element that is used to convert optical 
30 video and data signals sent from CO DSLAM 230 into electrical signals for deployment to 
the customer locations over electrical cable connections, such as twisted pair copper cable. 
The electrical signals may be combined with a telephone signal and are sent to customer's 
locations. By positioning RT DSLAMs 236 closer to customer locations, the reach of the 
high speed data service is extended. In one embodiment, RT DSLAM 236 is a node 
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positioned in a neighborhood (fiber-to-the-node deployment) and is configured to convert the 
optical video and data signals to electrical signals for deployment to a plurality of customer 
locations via cross box 238 used to serve that neighborhood. 

[35] In another embodiment, RT DSLAM 236 is a terminal node for fiber- 
to-the-curb deployment and feeds service to a customer location directly without the need for 
cross box 238. 

[36] In yet another embodiment, a RT DSLAM 236 is the network element 
that is suitable for location in a multiple dwelling unit (MDU), such as an office or apartment 
building. In this particular embodiment, RT DSLAM 236 is a variation of a terminal for 
fiber-to-the-node deployment and feeds service to the customers in the MDU directly and not 
through cross box 238 associated with a distribution area (DA). 

[37] If midloop 208 includes cross box 238, cross box 238 relays signals 
from RT DSLAM 236 from midloop 208 to the customer. 

[38] As shown, a customer network in plurality of customer networks 1 1 0, 
includes a home network and/or Customer Premise Equipment (CPE) 240. CPE 240 is 
coupled to the cross box 238 or RT DSLAM 236 if cross box 238 is not present and receives 
the video, data, and/or telephony signals. CPE 240 may be coupled to a TV 242, workstation 
244, and/or telephone 246. Thus, the customer can receive telephony, video, and/or data 
signals from the network. In one embodiment, CPE 240 may be replaced by other equipment 
capable of receiving signals from shared network 108. 

[39] It will be understood that a person of skill in the art will appreciate 
other ways of implementing network 102. Thus, network 102 is not limited to the above 
description. 

Network Element Inventory 

[40] Fig. 3 illustrates elements of network element inventory 106 according 
to one embodiment. As shown, network element inventory 106 includes network discovered 
physical inventory 302, network discovered logical inventory 304, and planned network 
inventory 306. Planned network inventory 306 may also include planned logical and planned 
physical inventory. 

[41] Network discovered physical inventory 302 and network discovered 
logical inventory 304 may also be parsed and normalized (Step 308) and loaded (Step 310) 
into network element inventory 106. However, the parsing and loading step may be 
unnecessary and network discovered logical inventory 304 and physical inventory 302 may 



be directly loaded into network element inventory 106. Parsing and loading network 
discovered physical inventory 302 and logical inventory 304 is done to normalize data 
received from different network elements because different network elements may send and 
manage data in different formats. 
5 [42] Network discovered physical inventory 302 includes physical 

inventory of the network that is self discovered by intelligent network elements of the 
network. Network discovered physical inventory 302 represents installed physical inventory 
of the physical network. In one embodiment, network discovered physical inventory 302 is 
created daily in element management system 104. As discussed above, EMS 104 is a central 
10 repository where self-discovered inventory information from network 102 is discovered and 
retrieved. The total installed inventory includes used (e.g., allocated to a customer), available 
(e.g., available for customer use) or possible (e.g., not available for customer use) network 
components. 

[43] Additionally, network discovered logical inventory 304 includes 

1 5 logical or virtual inventory of the network that is self discovered by intelligent network 
elements. In one embodiment, the logical inventory includes installed virtual paths and 
assignments. In one embodiment, network discovered inventory logical inventory 304 may 
be created in EMS 1 04. The logical inventory also represents the used and available logical 
inventory in network 102. 

20 [44] Planned network inventory 306 includes installed (with only a partial 

in use status) inventory, planned inventory, and pre-assigned planned inventory information. 
Planned network inventory 306 may be automated by including tools for operation systems, 
such as engineering, sales, and marketing, to enter planned network inventory into network 
element inventory 106. For example, once the engineering department develops spreadsheets 

25 or other documentation representing planned inventory, pre-assignments are entered into 
network element inventory 106 through a graphical user interface (GUI). 

[45] Additionally, in one embodiment, planned logical inventory is entered 
automatically into network element inventory 106 through a logical path automation process 
that facilitates management of Virtual Channel Indicator/Virtual Path Indicator (VCI/VPI) 

30 pools within the network. The pools of VPI/VCI links are created to support the flow of 
video and data to users over the network. The VPI/VCI links include the virtual or logical 
path that data is routed through over the physical network. In order to implement an 
automated VPI/VCI managed pool, a centralized system allowing entry of a virtual path into 
one manager or system or VPI/VCI administration system, which will propagate the same 



virtual path into multiple network elements is provided. Thus, the labor intensive task that 
involved entering the same information for the same virtual path into multiple network 
elements or systems (ATM switches, routers, CO DSLAM 230 and RT DSLAM 236) is 
avoided. 

[46] When construction of new equipment is completed or a user's report 
indicating that existing capacity is nearly consumed, an assignment process to decide 
VPI/VCI allocation is initiated. Once the allocation is completed, actual assignment needs to 
be configured in, for example, routers, ATM switches, CO DSLAM 230 and RT DSLAM 
236. 

[47] In the VPI/V CI system, an administrator enters the assignments into a 
VPI/VCI administration system. The system then takes those assignments and propagates the 
appropriate assignments to the network elements. Additionally, the system records the 
assignments and documents the assignments into network element inventory 106. Thus, 
multiple manual entries required for the routers, ATM switches, CO DSLAM 230, and RT 
DSLAM 236 are avoided. Further, the additional task of recording those assignments is 
avoided. Additionally, administrative errors are reduced because duplicate multiple entries of 
assignments do not need to be made and recorded. Also, when network elements are changed 
for capacity or for maintenance reasons, the entry of VPI/VCI information will have to be 
repeated for the new switch. However, the VCI/VPI administrative system will be able to 
repeat the location and assignment without any extra manual steps. Thus, network 
rearrangement work will not affect the allocation of VCI/VPI assignments. 

[48] In one embodiment, the planned network inventory 306 may include 
CO DSLAM 230 (e.g., broadband digital terminal (BDT) information) and/or RT DSLAM 
236 information. CO DSLAM 230 information may include, for example, an IP address, 
central office ID [CLLI code], relay rack, planned in-service date, number of cards, number 
ports per card, and planned job number associated with CO DSLAM 230 installation. 

[49] In one embodiment, RT DSLAM 236 information may include, for 
example, circuit ID of facility back to the central office, distribution area (DA) served by the 
RT DSLAM 236, wire center ID [CLLI code], cabinet ID [CLLI code], cabinet location 
(address), associated crossbox address, planned in service date, planned job number 
associated with RT DSLAM 236 installation and the number and type of cards within the RT 
DSLAM 236. 

[50] Additionally, planned network inventory 306 may include planned 
assignment (reservation) information. In one embodiment, the pre-assignment data includes 



CO DLSLAM 230 to RT DSLAM 236 assignment information. The assignment information 
includes how network 102 is connected from the CO 206 to crossbox 208. In a specific 
embodiment, the configuration and management of the facility connecting CO DSLAM 230 
with the RT DSLAM 236. 
5 [51] Network element inventory 1 06 may include a graphical user interface 

(GUI) to add, change, or delete planned inventory information. Additionally, in one 
embodiment, the addition or deletion of planned assignments (reservations) of cards to 
specific operation systems. Further, the system may provide a display of existing, consumed, 
spare, and planned additional capacity associated with a given central office 230 and/or RT 
10 DSLAM 236 location. 

[52] By integrating self-discovered, used and available inventory with the 
planned inventory, a single, consistent, and consolidated view is realized. This view may 
then be customized for access by other operation systems and organizations. 

[53] Figs. 4a-d illustrate a process for managing network element inventory 
15 106 and for product deployment for a xDSL sales service. In Fig 4a, a number of different 
operation systems are dependent on having access to network element inventory 106, such as 
the marketing 404, engineering 406, and sales 402 departments. Although sales 402, 
marketing 404, and engineering 406 departments are used to discuss the multiple operations 
systems, it will be understood that other operation systems may be included and access 
20 network element inventory 106. 

[54] The process includes marketing 404 providing a market forecast of 
expected demand and available capacity that needs to be built to meet demand to engineering 
406. Engineering 406 then plans and builds the network and assigns capacity to the network. 
Marketing 404 monitors the construction and provides sales 402 with forecast of capacity that 
25 may be sold. 

[55] Fig. 4b illustrates the engineering process in more detail. As shown, 
engineering 406 receives the marketing forecast. Additionally, engineering may receive a 
view of held orders, which are orders that were taken but were not filled, from network 
element inventory 106. Engineering 406 then makes a decision to build new physical 
30 network elements or modify existing physical network elements to increase capacity. In one 
embodiment, engineering 406 may build new network elements and/or modify network 
elements in either CO 206 midloop 208. To document the changes in CO 206 or midloop 
208, manual records are created to represent new and/or modified network elements and track 
the construction. Additionally, during the engineering design process, engineering 406 
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determines virtual associations or assignments between the installed network elements. 
These assignments define the virtual or logical path of data flow for customers. Engineering 
406 also keeps manual records of the assignments. The physical and virtual inventories are 
then entered into network element inventory 106 as planned inventory. 

[56] In Fig. 4c, marketing 404 is constantly monitoring the consumption of 
capacity of the network to enable marketing 404 to provide guidance to sales 402. The 
review is accomplished by querying network element inventory 106 for a view of planned 
and self-discovered logical and physical inventory information. From the view, marketing 
404 develops a tactical sales plan for sales 402 and a revised capacity forecast for engineering 
406. 

[57] In Fig. 4d, sales 402 receives a request for service. Sales 402 queries 
network element inventory 106 for network quality and service availability for that specific 
customer. Using network element inventory 1 06, sales 402 receives a desired view of 
information and processes the order based on self-discovered used and available and planned 
capacity. Additionally, sales 402 may verify network quality. 

Synchronization : 

[58] In order to ensure each operation system receives an accurate view of 
inventory of the network, network element inventory 106 synchronizes network discovered 
physical 302 and logical inventory with the planned inventory 306. By synchronizing the 
network inventory creates an accurate view of planned inventory 306, self-discovered 
physical 302, and logical 304 inventory. Typically, different views may be created for each 
operation system. For example, engineering 406 may need different inventory information 
than sales 402 and/or marketing 404. Thus, different views may be created for each group. 

[59] The view of inventory may be created using self-discovered physical 
302 and logical 304 inventory, planned inventory 306, and compared self-discovered and 
planned inventory. In some cases, planned and self-discovered inventory overlap and are 
compared by network element inventory 106 to determine if what was thought was built is 
what was actually built. If the comparison does not indicate planned inventory 306 matches 
self-discovered physical 302 and logical 304 inventories, network element inventory 106 may 
indicate that the inventories do not match or may choose one of the planned or self- 
discovered physical 302 or logical inventory 304. Additionally, a repair ticket may be issued 
or an operation system may be notified to investigate the discrepancy. In some cases, 
planned inventory 306 and self-discovered physical 302 and logical 304 inventories do not 
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overlap and thus, just the planned 306 or self-discovered physical 302 and logical 304 
information is included in the view. 

[60] As described above, network element inventory 106 is constantly 
accessed by different operation systems. For example, sales 402, marketing 404, and 
engineering 406 within an organization are different operation systems and require different 
views of the network element inventory. With the network continually changing, the 
departments may not receive an accurate view of the network inventory if network element 
inventory 106 is not updated. Thus, in order to ensure an accurate view of the network 
inventory, the network element inventory 106 is updated when changes, additions, or updates 
are made to the network in real-time. Additionally, network element inventory 106 may be 
updated when requests are made or on a periodic basis. 

[61] Thus, when changes, additions, and/or updates are made to the network 
and are received by network element inventory 106, they are synchronized with existing 
inventory. Once network element inventory 106 is synchronized, new views may be sent to 
the operation systems. Alternatively, new views may be provided only when they are 
requested and/or on a periodic basis. Thus, operation systems will be accessing accurate and 
current data from network element inventory 106. 

[62] Planned network inventory 306 is synchronized when changes or 
additions are made to network 102. For example, port/card updates are automatically 
synchronized when changes are made to the port/cards or port/cards are added to network 
102. Additionally, IOF/Fiber inventory is automatically updated and synchronized. Further, 
changes to VCI/VPI pools are automatically updated and synchronized. Thus, when a 
request for a view of network element inventory 106 is made, the inventory may be updated 
and synchronized before the view is sent to the requester. Therefore, an accurate and up-to- 
date view of the network inventory is provided. Additionally, when changes in the network 
element inventory are discovered, synchronized views may be sent to different operation 
systems automatically. 

[63] Physical 302 and logical 304 inventory is updated by network 102 self 
discovering the installed network elements. The update may be done nightly or in non-real- 
time, or may be done on a real-time basis using a polling process that automatically creates a 
current network inventory. Once the network is self-discovered, the self-discovered 
inventory is synchronized with the existing network element inventory. Thus, when a request 
is made, network element inventory 106 may be synchronized with non-real-time or real-time 
data before returning the request. 
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[64] Fig. 5 illustrates a method for managing a network element inventory 
according to one embodiment. In step S500, physical network inventory 302 is self- 
discovered by network 102. Self-discovered physical network inventory 302 may be 
discovered in real-time or non-real-time. 

[65] In step S502, logical network inventory 304 is self-discovered by the 
network. Self-discovered logical network inventory 304 may be discovered in real-time or 
non-real-time. 

[66] In step S504, planned network inventory 306 is provided. Once the 
physical 302, logical 304, and planned 306 network inventory is discovered, the inventories 
are loaded into network element inventory 106 (Step S506). 

[67] In step S508, physical 302, logical 304, and planned 306 inventories 
are synchronized. In step S510, a request for a view of network element inventory 106 is 
received. An accurate view of network element inventory 106 is then provided (Step S512). 

Uses of the Network Element Inventory 
Capacity Checking 

[68] Fig. 6 illustrates elements of a capacity calculating engine (CCE) 
environment 600 according to one embodiment. As shown, a capacity calculating engine 
602, sales graphical user interface (GUI) 604, other applications 606, and network element 
inventory 106 are shown. Additionally, network element inventory 106 includes held and 
pending order files. 

[69] Capacity calculating engine 600 receives requests for a determination 
of capacity for a network from sales consultants 608 and/or other users 610 through sales 
GUI 604 or other applications 606. Once receiving a request, CCE 602 communicates with 
network element inventory 106 to provide a calculation on capacity of network 102. In one 
embodiment, the capacity calculation is a calculation of possible and spare virtual and 
physical capacity. Additionally, the calculation may include a determination of network 
quality. 

[70] In one embodiment, capacity may be expressed in terms of possible 
and spare capacity. Possible capacity is a maximum number of users minus the enabled 
number of users for the network element. Maximum capacity is the maximum number of 
users a network element may support. However, the network element may not be enabled to 
provide service for the maximum number of users. For example, the network element may 
only be enabled to provide service for half of the maximum number. Thus, possible capacity 
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is the capacity not enabled to provide service. Spare capacity takes the enabling number into 
account and determines capacity as the number of users the network element is enabled to 
provide service minus the number of users currently using the service. For example, the 
network element may include a maximum number of ten ports. However, only five of the 
ports may be enabled to provide service. Of those five ports, three ports may be in use 
presently. Thus, possible capacity is five ports and spare capacity is two ports. In other 
words, two ports may be immediately enabled for service and five additional ports are 
available to provide service if enabled. 

[71] In one embodiment, capacity checking engine 600 determines spare 
VDSL port capacity of CO DSLAM 230 and RT DSLAM 236, such as BDTs, ONUs, 
USAMs, BNUs, and MDUs. Although the following description will be described in terms 
of capacity for these units, it will be understood by a person of skill in the art that capacity 
checking engine 600 may be able to check other network element capacities and is not 
limited to just VDSL port capacities. 

[72] In one embodiment, possible and spare capacity is calculated based on 
variations of video/data port capacities in different network elements. For example, the 
following table illustrates various RT DSLAM 236 types and their maximum video/data port 
capacity and maximum telephone port capacities according to one embodiment. 



RT Type 


Maximum 


Maximum Tel 




Video/Data Port 


Port Capacity 




Capacity 




BNU-8 


8 


12 


BNU-16&MDU 


16 


24 


BNU-1636 


16 


36 


USAM Split Brain Mode (OC-3) 


32 




USAM Single Mode (OC-3) 


16 


USAM Single Mode (OC-12) 


32 



RT DSLAM 236 Port Capacities 

[73] It should be understood that a reference table is being provided as an 
example and many variations of this table are contemplated. 

[74] In one embodiment, capacity checking engine 600 may check network 
1 02 for network quality to ensure the network is properly configured to offer service to the 
service area identifier. CCE 600 may set flags or return codes that indicate the quality of 
network 1 02. The following table illustrates examples of possible return codes according to 
one embodiment. 
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Normal 

Empty slots available for service 

BNU Telephony capacity exhausted 

One or more invalid input cable name format 

Central office not found 

One or more BDT/ODU combinations not found 
Too many BNU/MDU derived cables 
Fatal error 
TBD - future 

Return Codes Conditions 

[75] It should be understood that the conditions in the table are not mutually 
exclusive and any combination of these conditions may be returned. Also, the flags or return 
codes are not limited to the codes shown in the table. 

[76] Fig. 7 illustrates a method of determining capacity for network 102 
according to one embodiment. In one embodiment, capacity may be expressed in port 
quantities. In another embodiment, capacity may be expressed in terms of card or slot 
quantities. Cards or slots include a number of ports, such as two. The ports in the cards or 
slots are enabled to serve customers. 

[77] In step S 700, a request for capacity is received by capacity calculating 
engine 600. The request includes a service area identifier, which identifies a particular 
customer or group of customers. In one embodiment, the service area identifier may be a 
telephone number. The service area identifier is used to identify network elements or a path 
of network elements in network 102. In one embodiment, the identifier may include a wire 
center CLLI code (code of a CO 206) or cable designators for a RT DSLAM 236 (Fiber to the 
Node configuration) to cross box or RT DSLAM 236 (Fiber to the Curb configuration) to a 
service area identifier cable. 

[78] In one embodiment, the identifier is parsed to determine if it is in the 
proper format. An appropriate response code flag is then set. For example, a response code 
flag, such as one or more invalid input cable name format, is set if cable designators are not 
in a proper format. If all cable designations are not in a proper format, a fatal error may be 
returned.In step S702, network element inventory 106 is queried for data relating to the 
service area identifier. In one embodiment, a list of network elements related to the service 
area identifier is returned. 
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[79] In Step S704, CCE 600 determines the network elements to be checked 
from the service area identifier. Additionally, CCE 600 may test for and set a response code 
flag for either of the following conditions if either exist: if the information received from 
network element inventory 106 indicates CO 206 is not in the database, a flag, such as 
5 "central office not found" or "fatal error," may be returned, or if the received information 

indicates an RT is connected to central office 206 is not in the database, a flag indicating "one 
or more CO 206/RT DSLAM 236 combinations are not found" may be returned. Further, if 
all discovered CO 206/RT DSLAM 236 combinations are not in the database, a fatal error 
response may be returned. Also, fiber connections, such as OC-3c and OC-12c and special 
10 RT DSLAM 236 configurations, such as split brain mode, may be tested. 

[80] In one embodiment, CCE 600 may check and determine if telephony 
usage is at a maximum. In one embodiment, if RT DSLAM 236 and/or data service usage is 
at a maximum, a response code flag indicating that "plain old telephone service (POTS) 
T usage is at a maximum" may be set. 
15 [81] In Step S706, the identified equipment is checked to determine if the 

identified equipment has possible capacity available. In one embodiment, CCE 600 takes the 
maximum number of ports minus the number of ports present to determine the possible 
capacity. In one embodiment, CCE 600 may also determine a number of possible cards or 
slots available for service. In one embodiment, a response flag, such as "empty slots 
20 available for service" may be set if the number of ports present in the identified equipment 
are less than the maximum supported number of ports. 

[82] In Step S708, the spare video/data port capacity is calculated for each 
network element identified. CCE 600 determines the number of video/data ports present and 
the number of video/data ports in use for each network element identified. In one 
25 embodiment, the spare video/data port capacity is calculated as video/data ports present less 
the video/data ports in use. The calculation represents the number of spare physical ports that 
are presently available for service activation. 

[83] In another embodiment, the spare capacity calculation includes using a 
number of defective port/card slots and the number of possible port/card slots. In this 
30 embodiment, CCE 600 calculates spare capacity as the calculated spare capacity plus the 
number of possible video/data ports or cards minus the number of defective ports or cards. 

[84] CCE 600 adds the number of possible video/data ports to the spare 
capacity. By adding the number of possible video/data ports, service will not be denied if 
service may be offered by the network even if additional maintenance is needed to enable the 
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possible video/data ports. Also, the number of possible video/data ports may be added as 2 
video/data ports per possible card slot. In this case, it is assumed that there are 2 video/data 
ports per card or slot. 

[85] Additionally, CCE 600 subtracts the number of defective ports from 
the spare capacity. By subtracting the number of defective ports, a more accurate view of 
capacity is presented. A port may have been enabled for service but for some reason is 
defective and cannot deliver service. Thus, the defective port is not considered available for 
service. Additionally, defective possible ports are not taken into account in the capacity 
calculation. Also, the calculation may use cards instead of ports. In one embodiment, the 
number of defective video/data ports may be subtracted as 2 video/data ports per defective 
card slot. In this case, it is assumed that there are 2 video/data ports per card or slot. 

[86] In another embodiment, CCE 600 may use a number of held and 
pending orders to calculate spare capacity. In this embodiment, the CCE will compute the 
spare video/data ports capacity as the calculated spare video/data ports less the number of 
held or pending orders for the video service. The held and pending orders for the data service 
are not considered by the capacity checking engine. A reason video service held and pending 
orders are considered and not the data service held and pending orders is because the video 
service is given priority over data service. One reason video service is given priority is 
because of the potential for greater profits. However, in other embodiments, the data service 
held and pending orders may take priority over the video service or both the video and data 
service held and pending orders may be taken into consideration. The held and pending 
orders for video service are taken into account because capacity for pending video service 
should preferably not be taken up by other orders. A service provider does not want to 
replace a held and pending video service order with a data service order. 

[87] In another embodiment, the spare video/data port capacity may be 
broken down by distinguishing between video and data. For example, a number of data only 
ports in the spare video/data ports is returned with the spare capacity calculation. Different 
combinations of services may be enabled for a port. For example, a port may be enabled for 
video and data, video-only, and data-only. In one embodiment, it is desired to enable ports 
with video services and thus, priority is given to video and data service, and video only 
services. A reason for giving video priority is it is expected that video services are more 
profitable than data services. Thus, if the number of spare data-only ports are known, the 
remaining spare ports may be reserved for video, and data or video-only services. Thus, 
spare video data ports reserved for video services will not be reserved by data-only services. 
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However, in other embodiments, data services may be given priority over video services. 
The goal is to give priority to the most profitable services. 

[88] In Step S710, a response is assembled and sent to the requestor. In one 
embodiment, the total spare video/data port capacity for the service area identifier is reported. 
The total is the sum of the spare ports of each individual network element identified. The 
response may include any of the above calculations of spare capacity. Also, the response 
may include all the set response code flags indicating network quality. 

[89] Additionally, in one embodiment, the response message may include 
the following: the received wire center CLLI code, received cable designation(s), the parsed 
CO 206/RT DSLAM 236 combination, the set response code flags, and/or a spares available 
yes/no indicator. In one embodiment, the yes flag will be sent if the sum of the spare 
video/data ports at RT DSLAM 236 location is greater than five or if the sum of the spare 
video/data port at RT DSLAM 236 (Fiber to the Curb configuration) location is greater than 
one. If either of these conditions are not met, a no will be sent. In another embodiment, the 
spares available yes/no indicator will indicate yes if the total quality of the spare video/data 
ports is greater than zero for any of the available network elements for the service area 
identifier. If there are not spare video/data ports, then a no will be indicated. 

[90] Additionally, for each network element checked, a CO DSLAM 230 
and/or RT DSLAM 236 number, IP address, CK ID number, DSLAM type, RT DSLAM 236 
CLLI, address (location) and quantity of spare video/data ports present may be reported. 

[91] In one embodiment, if a failed error condition occurs with any of the 
above determinations by the CCE 600, a response to the query may include the following: a 
received wire center CLLI code received cable destinations, available pairs, response code 
(indicating all set conditions including the fatal error flag), spares available yes/no indicator 
of no, and zero as a spare video/data port quantity. Additionally, no individual CO DSLAM 
230 and/or RT DSLAM 236 assignment information may be returned. 

[92] Fig. 8 illustrates a method for handling customer inquiries for video 
and data service. Step S800, a customer inquires about possible service either through the 
web or through a sales consultant. The sales consultant then contacts the capacity checking 
engine to determine in real-time the loop quality and service availability (Step S802). In step 
S804, capacity checking engine 600 determines the loop quality of the network and spare 
capacity for a service area identifier for the customer. If there is service availability and 
capacity, the sales consultant may process the order for service (Step S808). However, if 
capacity is not available and/or there are not service availability, a sales consultant will 
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inform the customer that service is not available (Step S810). The sales consultant may 
approve or disapprove the request for service based on video and data port availability. The 
sales consultant may not want to fill up all video/data ports for the service area identifier and 
may decide to put a data only request on hold (Step S812). However, a sales consultant 

5 wants to receive as many video requests as possible and would approve a request for a video 
service over a data service (Step S814). 

[93] By using the CCE, a sales consultant is relieved of many manual tasks, 
such as referring to documents relating to capacity and also accessing computer databases 
and looking for and matching service area identifiers to entries in the database. These entries, 
10 in both cases, may be out of date. However, using the CCE, the requested data may be 
returned to the client or sales consultant in less than 2 seconds or in most cases within 
5 seconds. Thus, the CCE increases customer service and provides more reliable service to 

■*f customers requesting VDSL service. 

ifi In other embodiments, network element inventory 106 may be used to provide 

15, an inventory history. Additionally, in another embodiment, network element inventory 106 
/"! may be used by a web portal that allows users to view and/or manage network element 
4* inventory 106. 

The above description is illustrated but not restrictive. Many variations of the 
r;. 1 invention will become apparent to those skilled in the art upon review of this disclosure. The 
W : scope of the invention should, therefore, be determined not with reference to the above 
2 description, but instead should be determined with reference to the pending claims along with 
their full scope or equivalents. 
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